0X00 前言

玩 Windows 域渗透的时候经常会听到的就是黄金票据和白银票据的利用了(虽然比较老的技术，但是始终是强力的武器)。这两个概念是在 kerberos 的认证过程中出现的，咱们先不谈利用，就是从理解整个流程上看也是比较困难的，因为kerberos 的认证过程确实是比较复杂的，不仅记不住，而且可能看了又看最后还没找到整个过程中哪个是黄金票据哪个又是白银票据，我个人也是这样，于是才有了这篇文章。

0X01 Windows 的认证协议

Windows 的认证协议主要有两种，一种是 NTLM 另一种是 Kerberos

1.NTLM

NTLM 的认证机制是一种基于挑战、应答的Windows 早期的认证机制，因为其安全性不高，于是从 Windows 2000 开始已经默认不再使用，而是使用了 Kerberos 其作为域的默认认证协议，因为和本文关系不大，所以这里就不详细介绍了。

2.Kerberos

相对于ntlm而言,kerberos的认证方式就要复杂的多,因为它提供了一个集中式的认证方式,在整个认证过程中总共要涉及到三方:客户端、服务端和KDC(Kerberos起源于希腊神话，是一支守护着冥界长着3个头颅的神犬，在keberos Authentication中，Kerberos的3个头颅代表中认证过程中涉及的3方),在Windows域环境中,KDC的角色常常由DC(Domain Controller)来担任,Kerberos是一种基于票据的认证方式,票据(Ticket)是用来安全的在认证服务器和用户请求的服务之间传递用户的身份,同时也会传递一些附加信息,用来保证使用Ticket的用户必须是Ticket中指定的用户,Ticket一旦生成,在生存时间内可以被Client多次使用来申请同一个Server的服务(票据窃取问题)

下图是 Kerberos 的认证过程示意图：

此处输入图片的描述

注：这里面涉及到的一些名词缩写

  • KDC(Key Distribution Center):密钥分发中心，里面包含两个服务：AS和TGS
  • AS(Authentication Server):身份认证服务
  • TGS(Ticket Granting Server):票据授予服务,该服务提供的票据也称为 TGS 或者叫白银票据
  • TGT(Ticket Granting Ticket):由身份认证服务授予的票据(黄金票据)，用于身份认证，存储在内存，默认有效期为10小时

0X02 分析开始

认证的核心目的就是让通信双方确认对方的真实身份，那么如果一个客户端要和一个服务器端通信，该怎么认证呢？我们现在一步步开始分析

1.初步思考共享密钥模式

首先我们想客户端可以把自己的身份信息，以及通过双方共享的密钥加密后的身份信息打包一起发给服务器，然后服务器通过与客户端共享的密钥解密，再和传过来的明文的身份信息比对来确认客户端的身份。

看上去很不错，但是你有没有想过他们是怎么共享这个密钥的呢？那这个时候密钥分配中心 KDC 这个角色(KDC往往由 DC 充当，并且有着所有客户端和服务器的 master key–>也就是密码对应的 Hash值 )就要排上用场了(而且这个共享秘钥还不能是简单的使用客户端密码的 hash 值这种长时间不变的值，因为长时间不变的值就给了攻击者足够的时间去破译)

2.KDC 作为可信第三方分配共享密钥Skey1

KDC 可以在客户端请求与服务器通信的临时密钥 Skey1 的时候，根据客户端提供的通信双方的身份信息从数据库中找到他们各自的 master key 然后分别加密两份 Skey1 ，一份给客户端，另一份给服务器端(发送给服务器端的内容除了 Skey1 以外还有 客户端的身份信息，用来待会客户端与服务器端通信时进行确认身份，其实Skey1和客户端身份信息合起来就是后面将会说的 TGS 也就是白银票据，可见白银票据是使用 服务器端的 master key加密的，是针对某个具体的服务器的，虽然伪造可以跳过 KDC 的认证，但是其影响面相对较小)，然后为了免于服务器端维护一个客户端和 Skey1 对应列表的负担，这两个信息都会先发送给客户端保存。

然后客户端通过自己的 master key 解密自己的那份信息(如果客户端是伪造的，不知道自己的 master key 则无法解密 KDC 发过来的信息)，然后用解密出来的 Skey1 加密自己的身份信息和一个时间戳(防止重放)，连同之前从KDC 得到的本来应该给服务器的那个用服务器端的 master key 加密的信息(TGS 白银票据)一同发送给服务器端，服务器端用自己的 master key 解密属于自己的那份信息(TGS 白银票据)，得到了 Skey1 和 客户端的身份信息，然后再用 Skey1 解密客户端发来的身份信息(这时候要校验时间戳是不是在可接受的范围内)，两者对比一下，从而认定客户端的身份。

我们发现，上面的步骤已经是的客户端和服务器端的认证过程使用了 Skey1 这个有短期时效的共享密钥，这样的话下一次想要通信的的时候只要该密钥没有过期就能免于之前的 KDC 重新生成一个 Skey1的繁琐步骤。但是你会发现客户端和 KDC 之间也是有类似客户端和服务器的身份认证过程，但是他们两个之间共享的唯一的密钥就是客户端的 master key 这个长期值(我们之前说过长期不变的值是不能作为共享密钥使用的，这会给了攻击者攻破的机会)，而客户端和 KDC 的认证过程又是非常重要的，因为这个过程负责传递给客户端 TGS(白银票据)，这也是整个身份认证的关键，所以我们还的想一个办法解决，从而让客户端和 KDC 之间的身份认证也用一个 短期密钥 Skey2 实现。

3.TGT 出现解决客户端与 KDC 的密钥共享问题

介绍这节之前先要说一下 KDC 的 AS 和 TGS，其实 KDC 就分成这两个部分，见下图：

此处输入图片的描述

客户端将会从 AS 中获取 TGT(黄金票据) ，然后从 TGS 中获取 TGS(白银票据)

为了解决上一节提到的问题，TGT 出现了，客户端从 KDC 的 AS 获取这个票据以后，客户端就能向 KDC 的 TGS 申请 TGS(Skey1+客户端身份信息) 票据(这个票据是客户端用于向服务器申请与服务器进行通信的票据，详情请见上一节)

客户端向 KDC 的 AS 申请 TGT(这里客户端首先要用自的 master key 加密自己的身份信息和 KDC 的信息，这样是为了让 KDC 知道客户端是真的知道自己的 master key ，而不是随便一个人的请求) 后，KDC 的 AS 会生成一个短期共享密钥 Skey2 ，然后分别用客户端和 KDC 的 mastet key(实际上这个 master key 就是 krbtgt 的 hash ) 进行加密(用 KDC master key 加密的除了 Skey2 以外还有客户端的身份信息，其实这两个被加密的信息合起来就是 TGT ，也就是我们常常说的黄金票据，可见，这个票据是针对 KDC 的，而没有指定服务器，因此影响范围较大)，然后一并发送给客户端。

客户端用自己的 master key 解密获取到 Skey2 ，然后用这个Skey2对客户端的身份信息以及想要访问的服务器的身份进行加密，连同刚刚获取的用 KDC 的 master key(krbtgt 的 hash )加密的数据一同发送到 KDC 的 TGS ，从而请求获取 TGS 票据，KDC 通过自己的 master key(krbtgt 的 hash) 解密数据，得到 Skey2 和客户端的身份，再通过 Skey2 解密客户端发来的另一个消息，确认客户端的身份，并且还能得到客户端想要访问的服务器，这样我们就又进入了我们之前讲过的第一步 “KDC 作为可信第三方分配共享密钥Skey1”

0X03 伪造票据的利用方法

上一节中详细介绍了 Kerberos 的认证过程，并且指明了认证过程中的 TGT 就是所谓的黄金票据， TGS 就是所谓的白银票据，那么我们在攻击中该怎么利用呢？这是我们这一小节的内容

1.黄金票据(Golden Ticket)

先假设这么一种情况,原先已拿到的域内所有的账户hash,包括krbtgt这个账户,由于有些原因导致域管权限丢失,但好在你还有一个普通域用户权限,碰巧管理员在域内加固时忘记重置krbtgt密码,基于此条件,我们还能利用该票据重新获得域管理员权限,利用krbtgt的HASH值可以伪造生成任意的TGT(使用 mimikatz),能够绕过对任意用户的账号策略,让用户成为任意组的成员,可用于Kerberos认证的任何服务(如果你看到这里还是不理解为什么有了 krbtgt hash 就能伪造一切，请回到上面再仔细地分析一下整个流程)

2.白银票据(Silver Ticket)

通过观察Kerberos协议的认证过程不难发现,如果我们获取了服务器端的 master key ,就可以伪造 TGS 从而跳过KDC的认证，直接和目标Server通信

0X04 关于黄金票据和白银票据的一些区别:

1.访问权限不同

(1)Golden Ticket: 伪造TGT,可以获取任何Kerberos服务权限
(2)Silver Ticket: 伪造TGS,只能访问指定的服务

2.加密方式不同

(1)Golden Ticket 由Kerberos的Hash—> krbtgt加密
(2)Silver Ticket 由服务器端密码的Hash值—> master key 加密

3.认证流程不同

(1)Golden Ticket 的利用过程需要访问域控(KDC)
(2)Silver Ticket 可以直接跳过 KDC 直接访问对应的服务器

0X05 总结

本文简单的梳理了一下 Kerberos 的认证过程(可能需要一点密码学的基本知识)，虽然没有配图，不过我觉得我讲的条例还算清晰，至少我是把我自己给说懂了,hhh，图以后有时间再一点点配吧。

0X07 参考链接

https://blog.csdn.net/wulantian/article/details/42418231
https://klionsec.github.io/2016/08/10/ntlm-kerberos/
https://adsecurity.org/?p=1515
http://www.mottoin.com/tech/119164.html
https://adsecurity.org/?p=1640